Handling of event trigger registrations on BBERF during hand-over

ABSTRACT

Various exemplary embodiments relate to a method performed by a policy and charging rules node of provisioning event triggers. The method may include: receiving, from a requesting node, a request to provision a set of event triggers on a primary gateway; forwarding, to the primary gateway, the set of event triggers; storing the set of event triggers in association with a session; detecting a handover of the session; determining a new primary gateway; and forwarding, to the new primary gateway, the set of event triggers. The method may further include: receiving a message; determining whether the message includes the same set of event triggers; if the message includes the same set of event triggers, refraining from sending the set of event triggers to the primary gateway; and if the message includes a different set of event triggers, forwarding the different set of event triggers to the primary gateway.

TECHNICAL FIELD

Various exemplary embodiments disclosed herein relate generally totelecommunications networks.

BACKGROUND

As the demand increases for varying types of applications within mobiletelecommunications networks, service providers must constantly upgradetheir systems in order to reliably provide this expanded functionality.What was once a system designed simply for voice communication has growninto an all-purpose network access point, providing access to a myriadof applications including text messaging, multimedia streaming, andgeneral Internet access. In order to support such applications,providers have built new networks on top of their existing voicenetworks, leading to a less-than-elegant solution. As seen in second andthird generation networks, voice services must be carried over dedicatedvoice channels and directed toward a circuit-switched core, while otherservice communications are transmitted according to the InternetProtocol (IP) and directed toward a different, packet-switched core.This led to unique problems regarding application provision, meteringand charging, and quality of experience (QoE) assurance.

In an effort to simplify the dual core approach of the second and thirdgenerations, the 3rd Generation Partnership Project (3GPP) hasrecommended a new network scheme it terms “Long Term Evolution” (LTE).In an LTE network, all communications are carried over an IP channelfrom user equipment (UE) to an all-IP core called the Evolved PacketCore (EPC). The EPC then provides gateway access to other networks whileensuring an acceptable QoE and charging a subscriber for theirparticular network activity.

The 3GPP generally describes the components of the EPC and theirinteractions with each other in a number of technical specifications.Specifically, 3GPP TS 29.212, 3GPP TS 29.213, and 3GPP TS 29.214describe the Policy and Charging Rules Function (PCRF), Policy andCharging Enforcement Function (PCEF), and Bearer Binding and EventReporting Function (BBERF) of the EPC. These specifications furtherprovide some guidance as to how these elements interact in order toprovide reliable data services and charge subscribers for use thereof.

SUMMARY

A brief summary of various exemplary embodiments is presented. Somesimplifications and omissions may be made in the following summary,which is intended to highlight and introduce some aspects of the variousexemplary embodiments, but not to limit the scope of the invention.Detailed descriptions of a preferred exemplary embodiment adequate toallow those of ordinary skill in the art to make and use the inventiveconcepts will follow in later sections.

Various exemplary embodiments relate to a method performed by a Policyand Charging Rules Node (PCRN) of provisioning event triggers. Themethod may include: receiving, from a requesting node, a request toprovision a set of event triggers on a primary gateway; forwarding, tothe primary gateway, the set of event triggers; storing the set of eventtriggers in association with a session; detecting a handover of thesession; determining a new primary gateway; and forwarding, to the newprimary gateway, the set of event triggers.

In various alternative embodiments, the method further includes:receiving a message from a network node; determining whether the messageincludes the same set of event triggers as the stored set of eventtriggers; if the message includes the same set of event triggers,refraining from sending the set of event triggers to the primarygateway; and if the message includes a different set of event triggers,forwarding the different set of event triggers to the primary gateway.

In various alternative embodiments, the step of detecting a handover ofthe session includes receiving a message from the new primary gateway.The method may further include: receiving a message from the requestingnode; determining whether the message includes a different set of eventtriggers; determining whether the message indicates a primary gateway;and if the primary gateway is the same as the new primary gateway andthe message includes the stored set of event triggers, refraining fromsending a message to the new primary gateway.

In various alternative embodiments, the step of forwarding the set ofevent triggers includes sending the set of event triggers in a reply tothe message from the new primary gateway.

In various alternative embodiments, the step of detecting a handover ofthe session includes receiving a message from the requesting node. Thestep of forwarding, to the new primary gateway, the set of eventtriggers may include sending a reauthorization request to the newprimary gateway. The method may further include receiving a reply fromthe new primary gateway indicating that the event triggers have beeninstalled.

In various alternative embodiments, the requesting node is a packet datanetwork gateway or a policy control and enforcement node.

In various alternative embodiments, the step of storing the set of eventtriggers includes storing a bit mapping of event triggers.

Various exemplary embodiments relate to the above described methodencoded on a tangible and non-transitory machine-readable storage mediumas instructions for execution by a network element.

It should be apparent that, in this manner, various exemplaryembodiments enable a method of handling event trigger registrations on aBBERF during handover. In particular, by saving the Event RegistrationIndication, the PCRN may ensure that the BBERF at the primary SGW iscorrectly provisioned with a set of event triggers requested by the PGW.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to better understand various exemplary embodiments, referenceis made to the accompanying drawings, wherein:

FIG. 1 illustrates an exemplary communications network;

FIG. 2 illustrates an exemplary policy and charging rules node;

FIG. 3 illustrates a message passing diagram showing an exemplary methodof processing a handover;

FIG. 4 illustrates a message passing diagram showing another exemplarymethod of processing a handover; and

FIG. 5 illustrates a flowchart showing an exemplary method of processinga session update from a PGW.

DETAILED DESCRIPTION

The 3GPP specifications, 3GPP TS 29.212 in particular, indicates thatonly the primary BBERF should be provisioned with event triggers. In thecase of a handover, where the primary BBERF changes, the event triggersmay be lost. A PGW or PCEF may request the event triggers to beprovisioned on the new primary BBERF.

A PCRN is positioned so that it receives status updates from variousnetwork nodes including SGWs containing BBERFs. A PCRN may store a setof required event triggers when it provisions the primary BBERF. A PCRNmay detect a handover and automatically provision the new primary BBERFwith the stored set of required event triggers. The PCRN may reducenetwork messages by screening duplicate requests arriving from multiplenodes.

Referring now to the drawings, in which like numerals refer to likecomponents or steps, there are disclosed broad aspects of variousexemplary embodiments.

FIG. 1 illustrates an exemplary subscriber network 100 for providingvarious data services. Exemplary subscriber network 100 may be acommunications network, such as an LTE or 4G mobile communicationsnetwork, for providing access to various services. In various exemplaryembodiments, subscriber network 100 is a public land mobile network(PLMN). The subscriber network 100 may include user equipment 110, basestations 120, evolved packet core (EPC) 130, and packet data network140.

User equipment 110 may be a device that communicates with packet datanetwork 140 for providing an end-user with a data service. Such dataservice may include, for example, voice communication, text messaging,multimedia streaming, and Internet access. More specifically, in variousexemplary embodiments, user equipment 110 is a personal or laptopcomputer, wireless email device, cell phone, television set-top box, orany other device capable of communicating with other devices via EPC130.

A base station 120 may be a device that enables communication betweenuser equipment 110 and EPC 130. For example, base station 120 a may be abase transceiver station such as an evolved nodeB (eNodeB) as defined by3GPP standards. Thus, base station 120 a may be a device thatcommunicates with user equipment 110 via a first medium, such as radiowaves, and communicates with EPC 130 via a second medium, such asEthernet cable. Base station 120 a may be in direct communication withEPC 130 or may communicate via a number of intermediate nodes (notshown). Note that in various alternative embodiments, user equipment 110may communicate directly with EPC 130. In such embodiments, base station120 may not be present.

In various embodiments, multiple base stations 120 a-n may be present toprovide mobility to user equipment 110. Each base station 120 a-n mayhave a limited range. As user equipment 110 approaches the limit of abase station's range, the signal may degrade. User equipment 110 may behanded over to a different base station to provide a better signal.

Evolved packet core (EPC) 130 may be a device or association of devicesthat provides user equipment 110 with gateway access to packet datanetwork 140. EPC 130 may further charge a subscriber for use of provideddata services and ensure that particular quality of experience (QoE)standards are met. Thus, EPC 130 may be implemented, at least in part,according to the 3GPP TS 29.212, 29.213, and 29.214 standards.Accordingly, EPC 130 may include a plurality serving gateways (SGW) 132a-n, a packet data network gateway (PGW) 134, a PCRN 136, and asubscription profile repository (SPR) 138.

A serving gateway (SGW) 132 may be a device that provides gateway accessto the EPC 130 to an end user of network 100. SGW 132 may be one of thefirst devices within the EPC 130 that receives packets sent by userequipment 110. Various embodiments may also include a mobilitymanagement entity (MME) (not shown). SGW 132 may perform a number offunctions such as, for example, managing mobility of user equipment 110between multiple base stations 120 a-n and enforcing particular qualityof service (QoS) characteristics for each flow being served.

In various exemplary embodiments, EPC 130 may include multiple SGWs 130a-n and each SGW may communicate with multiple base stations 120 a-n.For example, SGW 132 c is shown in communication with base stations 120c and 120 n. Each IP-CAN session for a user equipment 110 may beassociated with a primary SGW 132. The primary SGW 132 may be the SGWthat is currently actually transmitting data to and from the userequipment 110. A handover may occur when the SGW servicing a userequipment 110 changes due to, for example, movement of the userequipment or congestion at the primary SGW 132. One of the other SGWs132 may begin transmitting data to and from the user equipment 110.

In various implementations, such as those implementing the proxy mobileIP (PMIP) standard, SGW 132 may include a bearer binding and eventreporting function (BBERF). The BBERF at a primary SGW 132 may maintaina set of event triggers. An event trigger may indicate an event that theSGW 132 should report to PCRN 136. SGW 132 may receive a set of eventtriggers for each IP-CAN session for which the SGW is the primary SGW.SGW 132 may monitor user sessions for the set of event triggers and sendnotification to PCRN 136 when an event occurs. In various alternativeembodiments, more than one SGW may act as a primary SGW. In suchembodiments, each primary SGW may receive a set of event triggers.

Packet data network gateway (PGW) 134 may be a device that providesgateway access to packet data network 140 to an end user of network 100.PGW 134 may be the final device within the EPC 130 that receives packetssent by user equipment 110 toward packet data network 140 via SGW 132.PGW 134 may include a policy and charging enforcement function (PCEF)that enforces policy and charging control (PCC) rules for each servicedata flow (SDF). Therefore, PGW 134 may be a policy and chargingenforcement node (PCEN). PGW 134 may include a number of additionalfeatures such as, for example, packet filtering, deep packet inspection,and subscriber charging support.

PGW 134 may acquire information about the access network for makingdecisions using event triggers. In particular, PGW 134 may requestinformation regarding an SGW by requesting event triggers to beprovisioned on the SGW. PGW 134 may request PCRN 136 to provision anevent trigger at the SGW 132 and notify PGW 134 when the event occurs.PGW 134 may send PCRN 136 an event report indication (ERI) thatindicates a set of event triggers which SGW 132 should report to PGW 134via PCRN 136,

Policy and charging rules node (PCRN) 136 may make policy decisionsbased on network information. PCRN 136 may include a policy and chargingrules function (PCRF) that generates PCC and/or QoS rules forimplementing policy decisions. PCRN 136 may communicate with SGW 132 andPGW 134 via a Gxx and a Gx interface, respectively. PCRN 136 maygenerate and/or modify PCC rules to control how SGW 132 and PGW 134treat subscriber traffic. PCRN 136 may provision SGW 132 and/or PGW 134with event triggers for desired event information. PCRN 136 mayprovision an SGW 132 with event triggers requested by both PGW 134 andPCRN 136. PCRN 136 may also provision event triggers requested by anapplication function (not shown). PCRN 136 may maintain a record of theevent triggers provisioned for each SGW and each IP-CAN session.

Subscription profile repository (SPR) 138 may be a device that storesinformation related to subscribers to the subscriber network 100. Thus,SPR 138 may include a machine-readable storage medium such as read-onlymemory (ROM), random-access memory (RAM), magnetic disk storage media,optical storage media, flash-memory devices, and/or similar storagemedia. SPR 138 may be a component of PCRN 136 or may constitute anindependent node within EPC 130. Data stored by SPR 138 may include anidentifier of each subscriber and indications of subscriptioninformation for each subscriber such as, for example, subscribercategory, subscriber policies or plans, account balances, bandwidthlimits, charging parameters, and subscriber priority. SPR 138 may alsomaintain a record of current subscriber usage according to one or morecounters such as, for example, data volume (uplink, downlink, or total),time, or credits.

Packet data network 140 may be a network (e.g., the Internet or anothernetwork of communications devices) for providing data communicationsbetween user equipment 110 and other devices connected to packet datanetwork 140. Packet data network 140 may further provide, for example,phone and/or Internet service to various user devices in communicationwith packet data network 140.

FIG. 2 illustrates an exemplary policy and charging rules node (PCRN)136. PCRN 136 may include Gx interface 210, Gxx interface 220, handoverengine 230, and session information storage 240.

Gx interface 210 may be an interface comprising hardware and/orexecutable instructions encoded on a machine-readable storage mediumconfigured to communicate with a PGW such as PGW 134. Such communicationmay be implemented according to the 3GPP TS 29.212. Thus, Gx interface210 may receive requests for PCC rules and transmit PCC rules forinstallation. Gx interface 210 may further receive session informationincluding Event Report Indications (ERI). An ERI may be sent from PGW134 in a session update request using a Credit Control Request (CCR)message including the Event-Report-Indication AVP. TheEvent-Report-Indication AVP may include any number of Event-TriggerAVPs. Gx interface 210 may send a Credit Control Answer (CCA) message inresponse to a CCR.

Gxx interface 220 may be an interface comprising hardware and/orexecutable instructions encoded on a machine-readable storage mediumconfigured to communicate with an SGW such as SGWs 132. Suchcommunication may be implemented according to the 3GPP TS 29.212. Thus,Gxx interface 220 may receive requests for QoS rules and transmit QoSrules for installation. Gxx interface 220 may further receiveUE-originated application requests, session requests, and eventnotifications in the form of a CCR message. In the event of a handover,Gxx interface 220 may receive a CCR message from the new primary SGW132. If the SGW 132 is a new SGW for the IP-CAN session, the CCR mayinitiate a new gateway control session. If the SGW 132 has alreadyestablished a gateway control session, the CCR may update sessioninformation. When PCRN 136 receives a CCR indicating a handover, Gxxinterface 220 may respond with a CCA including a set of event triggers.

Handover engine 230 may include hardware and/or executable instructionsencoded on a machine-readable storage medium configured to determinewhen a handover occurs. Handover engine 230 may process messagesreceived via Gx interface 210 and Gxx interface 220. Handover engine 230may compare session identifiers and addresses included within thereceived messages to determine whether a handover has occurred. Forexample, if handover engine 230 receives a CCR message from a new SGWincluding a request for a new gateway control session, handover engine230 may determine that the new SGW is new the primary SGW.

Handover engine 230 may determine a set of event triggers when itdetermines that there has been a handover. Handover engine 230 mayaccess session information 240 to look up a set of event triggersprovisioned for the previous primary gateway. The provisioned eventtriggers may include event triggers provisioned upon request from a PGW134. Handover engine 230 may also determine whether PCRN 136 requiresadditional event triggers for the SGW 132. Handover engine 230 may thenuse Gxx interface 220 to send a message including the event triggers tothe SGW 132. The message may include an Event-Trigger AVP.

Session information storage 240 may include any machine-readable mediumcapable of storing session information for PCRN 136. Accordingly,session information storage 240 may include a machine-readable storagemedium such as read-only memory (ROM), random-access memory (RAM),magnetic disk storage media, optical storage media, flash-memorydevices, and/or similar storage media. Session information storage 240may store information related to subscriber sessions. In particular,session information storage 240 may store session identifiers andaddresses linking various sessions of the same subscriber such asgateway control sessions, Gx sessions, and IP-CAN sessions. Handoverengine 230 may access this information to determine when a handoveroccurs and which SGW is the primary gateway. Session information storage240 may also store a set of event triggers provisioned on the primarygateway for each IP-CAN session. The set of event triggers may beefficiently stored in a bit mapping of each individual event trigger toa single bit. Handover engine 230 may access the stored set of eventtriggers during a handover in order to provision the new primary gatewaywith the event triggers of the previous primary gateway.

FIG. 3 illustrates a message passing diagram showing an exemplary method300 of processing a handover. Exemplary method 300 may be performed bythe various nodes of communications network 100 such as, for example,PGW 134, PCRN 136, SGW 132 a, and SGW 132 b. Some steps are shown as amessage sent between nodes. It should be apparent that such a step mayinvolve a step of sending the message and a step of receiving themessage. Method 300 may begin at step 305.

In step 305, a first SGW 132 a may send a CCR message to initiate agateway control session with the PCRN 136. In step 310, PCRN 136 maysend a CCA message to SGW 132 a acknowledging the session request andproviding session information, such as, for example QoS rules for thesession.

In step 315, PGW 134 may send a CCR message to initiate a gatewaycontrol session with the PCRN 136. In step 320, PCRN 136 may send a CCAmessage to PGW 134 acknowledging the session request and providingsession information, such as, for example, PCC rules for the session. Invarious exemplary embodiments, steps 305 and 315 may occur in the otherorder. In either case, PCRN 136 may link the sessions in associationwith the same subscriber or same IP-CAN session.

In step 325 PGW 134 may send a CCR update message including an ERIrequesting a set of event triggers to be provisioned to SGW 132 a. Invarious exemplary embodiments, PGW 134 must include the ERI as aseparate update request without any other updates to the Gx session. Invarious alternative embodiments, PGW 134 may send the ERI in theestablishment request of step 315, in which case, steps 325 and 330 maybe skipped. In step 330, PCRN 136 may send a CCA message to PGW 134acknowledging the received ERI registration request. In step 335, PCRN136 may store the received ERI, for example, in session informationstorage 240.

In step 340, PCRN 136 may send a set of event triggers to SGW 132 a. Theset of event triggers may include those present in the ERI andadditional event triggers required by PCRN 136 and/or an applicationfunction. SGW 132 a may install the event triggers and begin monitoringfor the designated events. In step 345, SGW 132 a may send an RAAmessage to acknowledge receipt of the event triggers. At this point,communications network 100 may be properly processing an IP-CAN sessionbetween user equipment 110 and data packet network 140. If a subscribedevent occurs at SGW 132 a, it may be reported to PCRN 136 and PGW 134for processing.

In step 350, PCRN 136 may receive a CCR message from another SGW suchas, for example, SGW 132 b. The CCR message may request a new gatewaycontrol session or may request an update of an existing gateway controlsession for a non-primary SGW. In step 355, PCRN 136 may determinewhether the received CCR message indicates a handover. PCRN 136 maycompare session identifiers and addresses to determine whether thereceived CCR message indicates a handover. In step 360, PCRN 136 mayselect a primary gateway. The primary gateway may be chosen from amongSGWs 132 with a gateway control session for the subscriber or IP-CANsession. PCRN 136 may select the primary gateway according to sessioncharacteristics such as IP-CAN type and most recent session. In variousexemplary embodiments, it is likely that the SGW 132 b sending a CCRmessage will be selected as the new primary gateway.

In step 365, PCRN 136 may send a CCA message to SGW 132 b including aset of event triggers. The set of event triggers may be the same set ofevent triggers that was provisioned on the old primary SGW. PCRN 136 mayretrieve the saved ERI and other event triggers from session informationstorage 140 and include it in the CCA message. In various exemplaryembodiments, PCRN 136 may generate the CCA including the ERI eventtriggers without receiving additional input from PGW 134. Once the newprimary gateway has been provisioned with a set of event triggers, themethod 300 may end. Alternatively, method 300 may return to step 345,and PCRN 136 may wait for an indication of a handover.

FIG. 4 illustrates a message passing diagram showing another exemplarymethod 400 of processing a handover. Exemplary method 400 may beperformed by the various nodes of communications network 100 such as,for example, PGW 134, PCRN 136, SGW 132 a, and SGW 132 b. Some steps areshown as a message sent between nodes. It should be apparent that such astep may involve a step of sending the message and a step of receivingthe message. Method 400 may be similar to method 300 through step 445.Steps 405 through 445 may correspond to steps 305 through 345. Afterstep 445, communications network 100 may be properly managing asubscriber's IP-CAN session with event triggers provisioned at theprimary SGW 132 a.

In step 450, PGW 134 may send a CCR update message. The CCR updatemessage may include an event trigger AVP such as IP-CAN_CHANGE orAN_GW_CHANGE that indicates that PGW 134 has detected a change in theSGW. In various embodiments, the CCR update message may also include anERI. If the CCR update message does not include an ERI, steps 460, 465,and 470 may be skipped. In various alternative embodiments, PGW 134 maysend a second CCR message including an ERI. In step 455, PCRN 136 maysend a CCA message to PGW 134 acknowledging the CCR message.

If PCRN 136 receives an ERI from PGW 133, in step 460, PCRN 136 mayupdate the stored ERI with the ERI received from PGW 134. In step 465,PCRN 136 may send a set of event triggers including those in thereceived ERI to the current primary SGW 132 a. In step 470, currentprimary SGW 132 a may respond with an RAA acknowledging receipt of theset of event triggers.

In step 475, PCRN 136 may determine whether the CCR message indicates ahandover. PCRN 136 may compare session identifiers and addresses todetermine whether the received CCR message indicates a handover. In step480, PCRN 136 may select a primary gateway. The primary gateway may bechosen from among SGWs 132 with a gateway control session for thesubscriber or IP-CAN session. The primary gateway may be chosenaccording to IP-CAN type or most recent session.

In step 485, PCRN 136 may push a set of event triggers to the newprimary gateway SGW 132 b using an RAR message. In various exemplaryembodiments, PCRN 136 may send the RAR message without input from newprimary SGW 132 b. PCRN 136 may include event triggers from either asaved ERI or a new ERI received in step 450. In step 490, the newprimary gateway SGW 132 b may send an RAA message acknowledging receiptof the set of event triggers. Once the new primary gateway has beenprovisioned with a set of event triggers, the method 400 may end.Alternatively, method 400 may return to step 445, and PCRN 136 may waitfor an indication of a handover.

FIG. 5 illustrates a flowchart showing an exemplary method 500 ofprocessing a session update from a PGW 134. Method 500 may be performedby the various components of PCRN 136. Method 500 may begin at step 510and proceed to step 520.

In step 520, PCRN 136 may receive a CCR update message from PGW 134.Because PCRN 136 may receive a CCR update message from PGW 134 atdifferent times and under different conditions, PCRN 136 may determinehow to process the CCR update message. The method 500 may proceed tostep 530.

In step 530, PCRN 136 may determine whether the received CCR updatemessage includes an ERI. PCRN 136 may simply check to determine whethera Event-Report-Indication AVP is present in the received CCR. If the CCRincludes an ERI, the method 500 may proceed to step 540. If the CCR doesnot include an ERI, the method 500 may proceed to step 560.

In step 540, PCRN 136 may determine whether the ERI matches the savedERI for the subscriber or IP-CAN session. If the received ERI isidentical to the saved ERI, the method 500 may proceed to step 560. Ifthe received ERI is different than the saved ERI, the method 500 mayproceed to step 550.

In step 550, PCRN 136 may update the ERI stored in session informationstorage 240 with the received ERI. In step 555, PCRN 136 may send thereceived ERI to the primary SGW in a set of event triggers. PCRN 136 maydetermine the primary SGW based on the content of the received CCR. Invarious exemplary embodiments, PCRN 136 may use a RAR message to sendthe ERI. The method 500 may then proceed to step 560.

In step 560, PCRN 136 may determine whether the received CCR messageindicates a handover. For example, PCRN 136 may determine whether thereceived CCR message includes a notification of change in the SGWaddress or a change in the IP-CAN session. If the CCR message does notindicate a handover, PCRN 136 may refrain from sending a message to SGW132 and the method 500 may proceed to step 580, where the method ends.If the CCR does indicate a handover, the method 500 may proceed to step570.

In step 570, PCRN 136 may send the saved ERI to the primary gateway.PCRN 136 may determine the new primary gateway based on the contents ofthe received CCR. PCRN 136 may send the saved ERI using a RAR message.PCRN 136 may also uninstall the ERI at the former primary SGW. Themethod 500 may then proceed to step 580, where the method ends.

According to the foregoing, various exemplary embodiments provide for amethod of handling event trigger registrations on a BBERF duringhandover. In particular, by saving the Event Registration Indication,the PCRN may ensure that the BBERF at the primary SGW is correctlyprovisioned with a set of event triggers requested by the PGW.

It should be apparent from the foregoing description that variousexemplary embodiments of the invention may be implemented in hardwareand/or firmware. Furthermore, various exemplary embodiments may beimplemented as instructions stored on a machine-readable storage medium,which may be read and executed by at least one processor to perform theoperations described in detail herein. A machine-readable storage mediummay include any mechanism for storing information in a form readable bya machine, such as a personal or laptop computer, a server, or othercomputing device. Thus, a machine-readable storage medium may includeread-only memory (ROM), random-access memory (RAM), magnetic diskstorage media, optical storage media, flash-memory devices, and similarstorage media.

It should be appreciated by those skilled in the art that any blockdiagrams herein represent conceptual views of illustrative circuitryembodying the principals of the invention. Similarly, it will beappreciated that any flow charts, flow diagrams, state transitiondiagrams, pseudo code, and the like represent various processes whichmay be substantially represented in machine readable media and soexecuted by a computer or processor, whether or not such computer orprocessor is explicitly shown.

Although the various exemplary embodiments have been described in detailwith particular reference to certain exemplary aspects thereof, itshould be understood that the invention is capable of other embodimentsand its details are capable of modifications in various obviousrespects. As is readily apparent to those skilled in the art, variationsand modifications can be affected while remaining within the spirit andscope of the invention. Accordingly, the foregoing disclosure,description, and figures are for illustrative purposes only and do notin any way limit the invention, which is defined only by the claims.

What is claimed is:
 1. A method performed by a policy and charging rulesnode (PCRN) of provisioning event triggers from a requesting node on aprimary gateway, the method comprising: receiving, from the requestingnode, a request to provision a set of event triggers on a first primarygateway providing a communication session; forwarding, to the firstprimary gateway, the received set of event triggers indicating eventsthat the primary gateway should report to the PCRN when an eventmatching one of the event triggers occurs at the first primary gateway;storing the received set of event triggers in association with thesession; detecting a handover of the session; determining a new primarygateway; and provisioning the new primary gateway by forwarding, to thenew primary gateway, the stored set of event triggers after detectingthe handover.
 2. The method of claim 1, further comprising: receiving amessage from a network node; determining whether the message includesthe same set of event triggers as the stored set of event triggers; ifthe message includes the same set of event triggers, refraining fromsending the set of event triggers to the primary gateway; and if themessage includes a different set of event triggers, forwarding thedifferent set of event triggers to the primary gateway.
 3. The method ofclaim 1, wherein the step of detecting a handover of the sessioncomprises receiving a message from the new primary gateway.
 4. Themethod of claim 3, further comprising: receiving a message from therequesting node; determining whether the message includes a differentset of event triggers; determining whether the message indicates aprimary gateway; and if the primary gateway is the same as the newprimary gateway and the message includes the stored set of eventtriggers, refraining from sending a message to the new primary gateway.5. The method of claim 3, wherein the step of forwarding the set ofevent triggers comprises sending the set of event triggers in a reply tothe message.
 6. The method of claim 1, wherein the step of detecting ahandover of the session comprises receiving a message from therequesting node.
 7. The method of claim 6, wherein the step offorwarding, to the new primary gateway, the set of event triggerscomprises sending a reauthorization request to the new primary gateway.8. The method of claim 7, further comprising, receiving a reply from thenew primary gateway indicating that the event triggers have beeninstalled.
 9. The method of claim 1, wherein the requesting node is apacket data network gateway or a policy charging and enforcement node.10. The method of claim 1, wherein the step of storing the set of eventtriggers comprises storing a bit mapping of event triggers.
 11. Atangible and non-transitory machine-readable storage medium encoded withinstructions thereon for execution by a network element of atelecommunication network to provision event triggers from a requestingnode on a primary gateway, wherein said tangible and non-transitorymachine-readable storage medium comprises: instructions for receiving,from a requesting node, a request to provision a set of event triggerson a first primary gateway providing a communication session;instructions for forwarding, to the first primary gateway, the receivedset of event triggers indicating events that the primary gateway shouldreport to the network element when an event matching one of the eventtriggers occurs at the first primary gateway; instructions for storingthe received set of event triggers in association with the session;instructions for detecting a handover of the session; instructions fordetermining a new primary gateway; and instructions for provisioning thenew primary gateway by forwarding, to the new primary gateway, thestored set of event triggers after detecting the handover.
 12. Themachine-readable storage medium of claim 11, further comprising:instructions for receiving a message from a network node; instructionsfor determining whether the message includes the same set of eventtriggers as the stored set of event triggers; instructions forrefraining from sending the set of event triggers to the primary gatewayif the message includes the same set of event triggers; and instructionsfor forwarding the different set of event triggers to the primarygateway if the message includes a different set of event triggers. 13.The machine-readable storage medium of claim 11, wherein theinstructions for detecting a handover of the session compriseinstructions for receiving a message from the new primary gateway. 14.The machine-readable storage medium of claim 13, further comprising:instructions for receiving a message from the requesting node;instructions for determining whether the message includes a differentset of event triggers; instructions for determining whether the messageindicates a primary gateway; and instructions for refraining fromsending a message to the new primary gateway if the primary gateway isthe same as the new primary gateway and the message includes the storedset of event triggers.
 15. The machine-readable storage medium of claim13, wherein the instructions for forwarding the set of event triggerscomprise instructions for sending the set of event triggers in a replyto the message.
 16. The machine-readable storage medium of claim 11,wherein the instructions for detecting a handover of the sessioncomprise instructions for receiving a message from the requesting node.17. The machine-readable storage medium of claim 16, wherein theinstructions for forwarding, to the new primary gateway, the set ofevent triggers comprise instructions for sending a reauthorizationrequest to the new primary gateway.
 18. The machine-readable storagemedium of claim 17, further comprising, instructions for receiving areply from the new primary gateway indicating that the event triggershave been installed.
 19. The machine-readable storage medium of claim11, wherein the requesting node is a packet data network gateway or apolicy charging and enforcement node.
 20. The machine-readable storagemedium of claim 11, wherein the instructions for storing the set ofevent triggers comprise instructions for storing a bit mapping of eventtriggers.